Add committee bylaws #360
Add committee bylaws #360
Conversation
committee.rst
Outdated
| The voting process may result in a number of new members not equal to | ||
| the number of outgoing members. This is fine; the size of the committee | ||
| is not fixed. However, a new nomination process begins only when | ||
| membership drops below nine members. |
There was a problem hiding this comment.
Does (should?) this include renominations for current members?
There was a problem hiding this comment.
Also, I believe our goal was to keep the committee size around 10 members, so this last sentence should read
However, a new nomination process begins only when membership drops below ten members.
(I appreciate this isn't really the place to discuss the below, but I feel the the Committee has gone wrong; and one of the wrong things is there's no venue for feedback.) The Committee mailing list has just started a discussion about Haskell 2020. There was a separate Haskell Prime committee and process supposed to be doing that; but it has been moribund all this year. I rather doubt that the GHC Committee are the right people/priorities to discuss the Haskell standard -- even granted that GHC represents a de facto standard. @goldfirere has started a github page to record/discuss decisions. How do I contribute to that? I'm asking because there's two screamingly wrong things I see on it already. |
The discussion we just started was about a GHC 2020 "standard", which would just be a set of existing language extensions that can be enabled as one. We have no desire to take over the Haskell standard, but there have been many requests to reduce the boilerplate of repeatedly enabling all the myriad extensions people use, and a GHC 2020 standard is one solution that was floated recently and had broad support from the committee.
I agree that a wiki is not the best way to discuss which extensions belong in the hypothetical GHC 2020 standard, this concern was also raised on the list. One idea I just had was to create a separate repo in the |
|
Thanks @gridaphobe, and for your post to the Committee list.
I agree we don't want protracted discussions. So you don't want Uncle Tom Cobbley and all editting the wiki page. The decision should be only: is such-and-such an extension as currently implemented in GHC to be in or out? Thank you to Richard for the explicit criteria 1-5. I think those are about right, but possibly need tightening up because they allow too much room for interpretation/subjectivity. Specifically ... So what I see as wrong is there's two extensions, as currently implemented, that RAE evaluates as meeting his criteria 1-5; but which I evaluate as failing on at least 3 of those criteria. I'll mention there are other compilers for Haskell than GHC; and that at least one of them implements both those extensions; and implements them differently (in dark corner cases [**]); and indeed had already implemented them well before the H2010 standard. It was precisely because they fail on the sort of criteria RAE suggests that neither extension made it into H2010. [**] In those corner cases, my experience is that Hugs' implementation is better-disciplined than GHC's, and rejects programs that can lead GHC into type-incoherence. If we were to get into protracted discussions, I'd say Hugs is too conservative, GHC is too laissez-faire. |
|
To be clear: I never noticed that the wiki wasn't world-editable. I thought it was. Regardless, the conversation about GHC2020 really does belong elsewhere, and it seems the committee is looking at figuring out where. May I suggest that we return this thread back to the proposed bylaws? |
| 1. Add a new commit on top of the PR branch that: | ||
|
|
||
| a. Changes the filename of the proposal to correspond to the PR number. | ||
|
|
||
| b. Updates any metadata fields that may have changed in the template on ``master`` since | ||
| the PR branch split off. | ||
|
|
||
| c. Fills in these metadata fields as appropriate, including changing "is discussed" | ||
| to "was discussed". | ||
|
|
||
| 2. Merge the PR branch into master, and push. |
There was a problem hiding this comment.
I usually merge master into the PR, then update the metadata, then push to master. But we probably don’t care too much about the various ways of achieving the same result, so no change needed.
Co-authored-by: Joachim Breitner <mail@joachim-breitner.de>
Co-authored-by: Joachim Breitner <mail@joachim-breitner.de>
|
I've updated the proposal to remove the reference to October and to specify that all new members get three-year terms. |
|
Did you push? |
Yes, but to the wrong place. Should be fixed how. |
|
I'd like to submit this for a vote, @nomeata. |
nomeata
added
the
Pending committee review
Co-authored-by: Joachim Breitner <mail@joachim-breitner.de>
int-index
removed
the
Pending committee review
A meeting of the committee at ICFP led to an understanding that we need to codify our practices a bit. This is, thankfully, not a result of anything having gone wrong, but an agreement that our continued success requires a well-articulated foundation.
This PR is a stab at drafting bylaws. The committee did not discuss particulars, which are my own invention, and about which I expect suitable debate.
Note that this PR is set up to allow edits by the committee members; please feel free to edit my branch directly, especially with typos and formatting goofs.
Rendered bylaws, but there are a few other changes with this PR as well.